In conventional email systems an individual sending email (“the sender”) can fulfil an intention to send an electronic email to one or a number of persons (the “receiver”). Typically this happens when the subject matter of the message is of interest to the receiver, or when the sender deems that such information is pertinent to the receiver.
In conventional art the outset intention of the sender to identify a receiver for an email is not always realized to the satisfaction or intention of the sender. Oftentimes an incorrect receiver is identified and errors can occur. A single incorrect addressee in one email can result in many further incorrectly sent emails after the original email is sent, replied to, further replied to, forwarded and subsequent threads associated with the initial thread established by the sender. It is desirable to eliminate this class of error.
Corporate directories are used to record the list of employees that an organisation has. In some large organisations, for speed and local access reasons, the corporate directory is replicated or available in each of the countries that the organisation may have, for example, in IBM Lotus Notes®, the corporate directory maybe be replicated in total (so all entries in all geographies) or in part (the local directory may have the entries associated with the organisational unit, and cascading of other organisational units done programmatically by network referral to the other organisations). In organisations like IBM a central directory (e.g., bluepages) can be replicated in its entirety—simply through cloning of the Lightweight Directory Access Protocol (LDAP) directory, or simply accessed by all centrally. IBM, Lotus, and Lotus Notes, are registered trademarks of IBM Corporation in the United States, other countries or both.
In many cases individuals can have the same name, an example is the number of David Smiths in New York or Pat O'Murphys in Dublin. This is referred to as “common name” in LDAP terminology. In some Asia Pacific countries, cultural nuances are such that individuals are more likely to be named after popular names and the number of individuals with the same/similar name is much higher than in Western countries. Individuals in an organisation with the same or similar LDAP “common name” frequently receive emails that are not intended for them. For example, Pat O'Murphy is a Test Architect in Dublin (let's call him Pat-A). There is also another Pat O'Murphy in Dublin who is a finance manager (Let's call him Pat-B). On a weekly basis Pat-A receives approximately 20-30 emails intended for Pat-B. A number of these contain private and confidential data (e.g. salary details of employees, personnel action notices, acquisition information, organisational data intended for senior managers/directors). Clearly, Pat-A should not be receiving these emails. Likewise Pat-B receives emails intended for Pat-A. The current solution is for one Pat to forward the emails to the other Pat and correct the original sender by advising “you have copied the incorrect individual, please copy the correct gent in the future”. Similarly, for example, there may be a team in Winchester that has two David Smiths, one in Test and one in Development and they may sit a few desks apart and work on the same team. These gents see a greater frequency of error in terms of being on the wrong email. Assuming that there is another David Smith somewhere else in the organisation then all three would get more incorrect emails than the two Pat O'Murphys. Sometimes, a David may actually reply to another David's emails and, if an already existing context applies, then the response can motive regression as the new reply from the wrong person misses this context. Broadly speaking, in a large organisation there can be several thousand errors associated with name collision in email and calendar invitations. Oftentimes confidential information is sent to the wrong persons. Also, time and opportunity are lost due to latency.
Sending an email to one incorrect receiver is a single problem corrected when the correct receiver is identified. However, if the original email was copied then further instances of an incorrectly copied email can occur and re-occur indefinitely. If an incorrect addressee were diligent then each incorrectly addressed email received would be corrected and in Pat O'Murphy's case this might mean several hundred emails in a year.
There is also “historical latency”, where a thread that was corrected (as described above) may sit dormant for some time. An individual on that thread may need to use past contacts, and may resurrect any of the original threads that copied an incorrect receiver. That thread and all subsequent threads will effectively mature the same class of problems that the incorrect receiver may have already attempted to correct. When an incorrect receiver is copied the correct receiver is unaware (until corrected by the incorrect receiver) that an error has happened. If this individual is on vacation, out of the office, sick and so on then the correct receiver is oblivious to an action or set of actions that were intended for them. Time can be lost, opportunity can be missed and subsequent frustration can grow where the sender does not get a response to an reply, or repeated attempts to achieve a response.
Correcting the sender on the first occasion does not suffice. Specifically, receivers have noted that senders make the same mistake over and over again due to human error and forgetfulness. The larger the organisation, the higher the probability of name collision. Conventional email groupware systems allow a person to send an email to a recipient address found in a groupware directory. A person who wishes to send an email, will have an email account, an email client and access to the group directory. People are generally known by their common name, e.g. “John Doe”. When the sender wishes to send an email to a recipient, “John Doe”, the sender enters “John Doe”, into the “To” field of the email form, completes the subject line and body field and then clicks the send button. The email program locates the nearest address match in the directory and forwards the email to the matched recipient.
In such groupware email systems an organisation stores its people information as person records in a directory (for instance an LDAP directory). Each person has a number of attribute fields associated with their person record. One attribute, the common name, will contain “John Doe”. The common name is the name by which most if not all people are known. The directory system may allow multiple common names for the same person. Pertinently, the one attribute that distinguishes individuals in an LDAP directory is the DN (Distinguished Name). This name is more likely to be unique in the LDAP directory because it can be made up of other attributes: UID (universal id); C (country); OU (organisational unit); O (organisation). For example, dn: (uid=771803897, c=us, ou=bluepages, o=ibm.com).
Subsequently, an organisation can have several people who have the same common name, and generally administrators add an initial or alternative to distinguish the common name, for example “John A Doe”. This is useful if the Sender of the email knows that the middle initial of the recipient has been assigned. However, the majority of senders will just use “John Doe” in the To field of the email as this is how they conventionally know and address the individual either professionally, amongst peers, or socially. The email will be sent and may be received by the wrong “John Doe”. If the “John Doe” who receives this email tries to send on the email to the intended recipient it can be a hit and miss process. Most likely, the wrong “John Doe” just returns the email to the sender with comments like “I think you sent this email to the wrong person”.
One solution to incorrectly sent emails is to have individuals use a person's distinguished name in sending email. Instead of using “John Doe” they could instead use the UID “771803897”. However, this is not desirable by users who have to substitute common names that are used daily with names that cannot be remembered.
The state of the art that goes part way to solving the problem can be seen in IBM Lotus Notes by way of a “look ahead” capability. When the sender is typing in the receiver's name the “look ahead” will identify individuals with the same common name, and the sender can select one of these names. However, even with this in place the above problems are not addressed. For example, when a user is offline the “look ahead” capability is not available so no prompting occurs. Also, when the degree of overlap with the receiver's name is closest to a server-side (LDAP) fuzzy-matched resolution no options are present and an immediate resolution based on a “good match” is returned (which may be the wrong person). This may explain why David Smith and Pat O'Murphy are consistently frustrated by the same problems associated with receiving emails not intended for them.
Another workaround demonstrated in Lotus Notes is that the sender can motivate a permanent correction by adding the correct name to their personal address book. However, problems can still occur in instances where matching may resolve names outside of this list due to a best-fit programmatically being established first elsewhere (server side). Regardless, personal address books are generally used by individuals to add names of “friends” and to facilitate abbreviations. For example, a user may choose to add “Xiao Hei Wu/China” as “David” as this is the name he goes by and that the user is familiar with. When the user subsequently sends emails to “David” this gets resolved to the exact substitution places in the personal names and address book as “Xiao Hei Wi/China”.
Prior art software permits situations where the class of problems described above happen and in repeated ways. On the basis that common name collision is inherent in society and organisations it is fair to say that there are cost, time, opportunity, frustration, and latency problems associated with existing systems and methods for routing email that do not address the problem of name collision. It is the purpose of this invention to solve this.
The system and method used for describing common, distinguished, organisational, hierarchical and other parameters associated with a user's name is in the main generally consistent within prior art corporate directories. What differs is the means of extracting information and the programmatic methodology used to interrogate these.
To implement a change in the architecture of an existing corporate directory would not solve the above problems if an email system used more than more than one directory. Existing LDAP systems are established and have been in existence for some time and explore the solution from the perspective of the email system. This makes sense if it is considered that email systems are used by individuals that can be “offline”, and at that point in time will not have access to their conventional LDAP directory in non-connected mode.
US patent publication 2002/0188690-A1 describes a system and method for checking, validating and correcting email addresses so as to transmit email to an accurate host name's email account holder. The method of correction is a systematic parsing of the email address followed by validation of the substring components in an intelligent way. A validation of the remote domain and validation of a destination user in that domain to derive a successful end result (email arriving). This is intended primarily to pre-empt and solve problems in the area of delivery failures due to malformed email addresses such that a valid email address is reinforced and propagated on behalf of the user.
US patent publication 2004/0103162-A1 describes a system and method that alerts/warns a user of an email system of the addresses of an email message after the act of sending has been selected and before the action of send has been motivated. The art essentially represents an interim validation of the message addresses and permits both an intermediate validation and correction step to the user which may result in a manual correction to the addressees as well as a cancel. The art also describes a set of circumstances where such an interception is desired and needed.